Communication systems and networks are typically decomposed according to protocol layers which encapsulate various communication functions. The OSI model for example, which is well known in the art, prescribes seven layers in a communication network. Various Operation, Administration and Maintenance (OAM) functions are required in a communications network and these are typically specified at each communication layer for various reasons including to reduce dependencies between layers, to aid in fault isolation as well to deal with layer-specific or technology-specific issues within that layer. Examples of these types of functions include fault management (fault detection, fault verification and fault isolation) and performance management (loss, delay, delay variation measurement and availability). For example, OAM mechanisms are defined separately at layer 2 for protocols such as SONET and Ethernet, at layer 2.5 for ATM and MPLS and at layer 3 for IP. A general discussion of layered OAM requirements for layer 2 Virtual Private Networks (VPN) services can be found in “L2VPN OAM Requirements and Framework” (draft-ietf-12vpn-oam-req-frmk-06.txt) from the Internet Engineering Task Force (IETF), the contents of which are incorporated herein by reference. Examples of layer 2 OAM functions can be found in “OAM Functions and mechanisms for Ethernet based networks”, ITU-T Y.1731, an example of ATM OAM functions is found in ITU-T 1.610 “B-ISDN operation and maintenance principles and functions” February 1999, and an example of MPLS OAM can be found in RFC4379 from the Internet Engineering Task Force (IETF). The contents of all these specifications are incorporated herein by reference. At layer 3, various prior art exists, for example, as produced by the IP Performance Metrics working group (IPPM) of the Internet Engineering Task Force. In particular, “IPPM Metrics for Measuring Connectivity”, RFC2678, the contents of which are incorporated herein by reference, is used to measure various types of connectivity at the IP layer.
Likewise, the requirement to provide such OAM functions at the “messaging layer” for management of messaging system overlay networks is needed.
In the prior art, there are many examples of messaging systems that provide for loosely coupled message delivery between the message source and the receiving application (for one-to-one delivery) or receiving applications (for one-to-many delivery). Routing of messages can be based on named destinations, such as a topic, subject, queue or Web Service Address (WSA) as defined by the World Wide Web Consortium (W3C) or can be based on actual message content. The message system itself is typically implemented by one or more general purpose computer servers running middleware software or by custom-built message routers operating at layers 4-7 of the OSI model, above the network layer (layer 3 of the OSI model). In many cases, this “message layer network” is an overlay to an Internet Protocol (IP) network. Connectivity between middleware software entities running on distinct servers or between message routers is achieved using layer 4 protocols such as Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). In this manner, several middleware instances or message routers are linked together via layer 4 connections to form an overlay to the IP network, complete with its own topology and communication paths. Users of this message layer network are typically applications residing on separate computer equipment, which then establish communication with their serving middleware or message router via layer 4 connections as well. In this message layer overlay network, we find the same requirements to be able to perform fault management and performance management, as described previously. Existing mechanisms known in the art to perform OAM at layers 3 and below are insufficient to perform fault and performance management at the message layer because they operate at layers below the messaging layer.
Existing implementations of message layer networks, such as those implemented by Java Messaging System (JMS) implementations, do not provide for the ability to monitor the messaging overlay for connectivity, latency and proper functioning of the various overlay communication paths of the messaging layer.